This section is intended to introduce various aspects of the art, which may be associated with embodiments of the disclosed techniques. This discussion is believed to assist in providing a framework to facilitate a better understanding of particular aspects of the disclosed techniques. Accordingly, it should be understood that this section is to be read in this light, and not necessarily as admissions of prior art.
The developers of a software application may allow the application to have its functionality enhanced or modified after its original creation. The enhancements or modifications may be realized using a plug-in framework. The additional libraries of a plug-in may be dynamically loaded into memory at runtime by the executable application or one of its dependent libraries. Once loaded into memory, the plug-ins may interact with the software application via a series of pre-defined interfaces provided by the software application, also known as an Application Programming Interface (API). Software applications that provide a plug-in capability may also provide a mechanism whereby plug-in libraries added to the software application subsequent to its original creation can be discovered. Discovering a plug-in library may entail some type of configuration whereby the executable file, or one of its dependent libraries, can read the location of additional plug-in libraries and dynamically load those libraries into memory.
Because plug-in frameworks can be implemented using many different methods, often there are restrictions that place constraints on third parties wishing to implement a plug-in. These restrictions may be problematic in managed computing environments, such as large corporate computing environments, where an end user's ability to make updates to a local computing system is limited. Instead, a member of an Information Technology (IT) staff with elevated privileges manually installs plug-ins onto end users' workstations. This solution may become time-consuming and cost-prohibitive if the number of users is large, if the user base is geographically dispersed, or if there are frequent updates to the plug-ins to be installed. Moreover, this solution can lead to further issues if the configuration information for multiple plug-ins is commingled in a single configuration location, such as a single configuration file. In such cases, the updates to plug-in configuration can carry additional risk of corrupting other plug-ins or the host application itself. Another solution may include redeploying the entire host software application along with its associated plug-ins each time a plug-in is added or updated in the environment. While redeployment may help alleviate some of the potential corruption issues, it does not overcome the issues of large disperse user groups and frequent updates. It may also carry the additional burden of requiring extensive retesting of the host application whenever a plug-in update is performed.
U.S. Pat. No. 7,458,062 by Coulthard, et al. (hereinafter “Coulthard”), discloses a framework for accessing a remote system from an integrated development environment. A connection registry contains objects and subsystem objects, and the connection objects have attribute information for the remote system whereas the subsystem objects contain information specific to a particular tool and connection. Additionally, the framework may include a common user interface by which tools can be registered within a connection, or by which a new connection can be created. The framework may maintain connections and tools within an integrated development environment independent of the type of operating system used by the remote systems and the programming language of the tools.
The previously described methods may not function in the absence of a networked environment. Further, these methods may allow use of plug-ins only when the plug-in meets a particular privilege level. Additionally, these methods may not allow a user to select particular plug-ins.